This PR softens the condition that the number of joints and command_joints have to be equal: JTC now supports having less command_joints than joints.

This gives the opportunity to track the state and error of passive joints, especially joints that are not command_joints but a degree-of-freedom of the physical system.

As an example, see the cart-pole example in the following video (a pendulum on a cart). Now it is possible to send a swing-up trajectory of the pendulum including values of the cart and the pendulum joint, JTC will do the trajectory interpolation and publishes the full state including the desired values for the pendulum joint, but it finally only can command the cart-joint.

This PR does not directly address passive joints being part of a closed-loop kinematic chain, i.e., joints not being a degree-of-freedom of the system. One could track the trajectory of all joints being part of the closed loop, but the kinematics need to be solved in the hardware interface, e.g., by means of a transmission interface.

A future PR will propose a possibility to implement different control laws than PID, e.g., a state-space controller, which is in fact necessary to control the pendulum from the example above.

More implementation details

• command_joints must be a subset of joints if they don't have the same size.
• If they have the same size, a 1:1 mapping is assumed independent of the values of command_joints. (see check_interface_names_with_command_joints test)
• ~/controller_state topic uses a single joint_names vector for all fields. Hence, entries of the output field being not included in command_joints will be NaN.

This would break rqt_joint_trajectory_controller, I used now the required state interface instead of claimed hardware interfaces from the contoller_manager msg.